Modern aircraft comprise more and more electronic and computer systems to improve their performances and to assist the pilot as well as the crew members during their missions. Thus, for example, the fly-by-wire controls make it possible to reduce the mechanical complexity of transmission of controls to the actuators and therefore the weight associated with these controls. Likewise, the presentation of pertinent information items enables the pilot to optimize the flight paths and to respond rapidly to any detected incident. Such information items are, in particular, speed, position, heading, meteorological and navigational data. These electronic and computer systems as a whole generally are called the avionics.
For reasons of reliability, the avionics often was shared functionally by specific modules, also called LRU (abbreviation for Line Replaceable Unit in English terminology). According to this architecture, a point-to-point transmission mode is used between each module. Thus, for example, the flight controls are handled in a special device while the electrical supply is handled in another one. In this way, a specific function is associated with each module.
Furthermore, each module supporting a critical function preferably is redundant so that the failure of one module does not bring about the loss of the associated function. The use of an aircraft utilizing a redundant module when the main module is faulty may necessitate a maintenance operation.
In order to improve the functionalities of the aircraft, to reduce the weight of the electronic equipment items by virtue of a greater integration, to reduce the costs by virtue of the use of generic modules, and to facilitate maintenance operations, the avionics now is more and more integrated according to an architecture called IMA (abbreviation for Integrated Modular Avionics in English terminology). According to this architecture, the functionalities of the avionic systems use as much as possible the generic computation and input/output resources in which they are implemented. These resources are distributed in the equipment items which each comprise numerous software modules. A system of segregation or partitioning makes it possible to isolate each of the functionalities so that the failure of one function does not affect another one.
By way of illustration, patent application FR 2 903 511 describes such an architecture.
Within each equipment item of the aircraft, software modules are loaded and updated by an operator who is on board the aircraft to perform these operations. The role of the operator is in particular to start the loading of these modules or these updates and to verify that the selected configuration has been properly loaded into the equipment item.
These operations typically are performed by using a centralized loading system that makes it possible to address all of the downloadable equipment items.
FIG. 1 illustrates an exemplary aircraft 100 comprising an on-board data processing system 105. System 105 itself comprises a communication network 110, for example a communication network in accordance with the AFDX (abbreviation for Avionic Full DupleX in English terminology) standard, to which equipment items here referenced 115 to 135 are connected. Some of these equipment items may have a specific role in the context of loading and updating software modules in the equipment items. Thus, for example, equipment item 115 may comprise a software module providing a centralized loading system function making it possible to address all of the downloadable equipment items, itself among others. Still by way of illustration, equipment item 120 may be used as storage location, also called repository in English terminology, for storing software modules to be installed on equipment items. Equipment 120 then typically comprises a reading device, for example a memory card reader or a DVD reader, making it possible to transfer software modules coming from the components manufacturers into the storage location.
The software modules generally are supplied by components manufacturers in the form of loads, that is to say assemblies comprising software applications or functions as well as elements that cannot be falsified making it possible to authenticate these software applications or functions, that is to say to demonstrate the integrity and origin thereof.
The operations to be carried out by an operator for loading equipment items may be different from one equipment item to another, in particular according to constraints peculiar to certain equipment items. Such constraints may be multiple. They may relate, for example, to orders of installation or erasures. They are linked to the complexity of the software modules and their interactions.
In order to take these constraints into consideration, the designers of on-board data processing systems generally write up procedures that are to be followed by the operators during operations of loading and updating software modules. Nevertheless, such procedures complicate the operators' operations, are time-consuming for them and constitute a potential source of problems linked to errors in handling.
In order to limit these problems, the implementation of constraints may be performed with the aid of functions for processing by lots, called batch functions. A batch function here is a function making it possible to implement the installation of software modules automatically in a given order. Nevertheless, this function does not cover all the types of constraints. Moreover, batch functions may be regarded as a translation of procedures. Consequently, the use of batch functions instead of procedures only shifts a part of the complexity linked to the operators' procedures to the programming of batch functions. Finally, the number of batch functions to be implemented is linked directly to the number of possible cases of loadings of software modules, which is prohibitive for a standard solution.
A need therefore exists, in on-board systems, in particular aircraft on-board systems, to manage constraints during installation or updating of software modules, making it possible to define uniform procedures for the operators responsible for these operations. The management of constraints preferably should not require modification of the loads generated by components manufacturers so that it is not necessary to modify the existing loads (so that the existing loads are usable without modification).